Summary

• DELETE /auth/me returns 500 for any user with a linked OAuth account. Adding cascade="all, delete" to User.oauth_accounts makes the ORM delete children first instead of trying to NULL the FK.
• Unhandled-exception 500s ship without CORS headers, so browsers misreport them as "No Access-Control-Allow-Origin header" instead of surfacing the real failure. A new Exception handler re-derives the CORS headers on the response itself.

Root causes

Cascade. User.oauth_accounts had no cascade= set, so SQLAlchemy's default (save-update, merge) fired on session.delete(user). The ORM emitted UPDATE oauth_account SET user_id = NULL ... as a "disassociate children" step before the parent delete; the NOT NULL constraint on oauth_account.user_id rejected it with NotNullViolationError, surfaced as a 500.

Verified in Cloud Run logs for a real failing request:

sqlalchemy.exc.IntegrityError: ...NotNullViolationError:
null value in column "user_id" of relation "oauth_account" violates not-null constraint

Postgres' ON DELETE CASCADE on the FK would handle this cleanly if the ORM stayed out of the way, but the ORM steps in first. Two ways to fix it: cascade="all, delete" (ORM emits explicit DELETEs for children) or passive_deletes=True (ORM yields to the DB cascade). I went with just the first — passive_deletes=True would silently break the SQLite test harness, which defaults to foreign_keys=OFF. The slight perf cost (one DELETE per linked oauth_account row) is negligible for an account-deletion endpoint.

CORS on 500. Starlette's build_middleware_stack splits exception handlers into two buckets:

for key, value in self.exception_handlers.items():
    if key in (500, Exception):
        error_handler = value           # → ServerErrorMiddleware (outermost)
    else:
        exception_handlers[key] = value # → ExceptionMiddleware (innermost)

ServerErrorMiddleware is the absolute outermost layer of any Starlette app — Starlette wires it that way deliberately. The 500 it emits travels through the outer ASGI send, never the wrapped send that CORSMiddleware uses to inject its headers. Result: every unhandled exception comes back to the browser without CORS headers, and the real failure (server-side bug) is hidden behind a generic CORS complaint.

The fix re-derives the CORS headers (matching cors_origin_list / cors_origin_regex from app/config.py) inside the exception handler and attaches them to the response. Same logic CORSMiddleware runs, just emitted at the response level instead of the middleware level.

Tests

tests/test_delete_account.py covers both:

• test_delete_me_succeeds_for_user_with_linked_oauth — seeds a Steam-OAuth user + linked oauth_account row, hits DELETE /auth/me, asserts 204 and that both rows are gone. Reproduces the original 500 if the cascade is removed.
• test_unhandled_exception_response_includes_cors_headers — forces an uncaught RuntimeError from a dependency, asserts the 500 carries Access-Control-Allow-Origin and Access-Control-Allow-Credentials. Uses ASGITransport(raise_app_exceptions=False) because Starlette's ServerErrorMiddleware re-raises after sending the response (a debug-tooling convenience that httpx propagates by default).

Test plan

• CI passes
• On a deployed test environment, sign in as a Steam-OAuth user and DELETE /auth/me from the auth frontend — expect 204 and the toast clears
• Force a 5xx (e.g. point at a broken DB once) and verify the browser surfaces "Internal Server Error", not a CORS message